Describe the bug
the Battery Buffer uses long Type to handle energy amount
so it overflows when there are more than 9,223,372,036,854,775,807 EU in it
it will cause many other bugs related to the energy system

Versions
Forge: 14.23.5.2860
GTCEu: gregtech-1.12.2-2.1.4-beta.jar
Modpack: GregTech Expert 2

Setup
SP/MP
New world generated

Steps To Reproduce
put two filled Ultimate Batteries into a Battery Buffer

Expected behavior
Battery Buffer can handle EU bigger than 9,223,372,036,854,775,807

Screenshots

Additional context
it will cause energy dupe because the Battery Buffer can output negative EU

This is limitation of current design and there is no easy way to handle this situation. Given that filled Ultimate Battery is not something normally used this is real edge case, which is not worth to solve.

Well yes, that is correct but certainly trivial to handle (NaN & infinity).
Using BigInteger also seems like a bad solution, due to increased memory allocation for holding an array of longs instead of a singular longs, where each operation is performed on potentially requiring several cpu cycles for performing basic operations.
Also: working with bigints is ugly, wish java would have operator overloads for them.

Simple signed int64 overflows still should be addressed. As long as you don't introduce floating point EU values, representation via doubles could be feasible, doubles are 194E287 times larger than longs and do not loose meaning full precision as long as you don't introduce a floating point. You also could potentially use floats if you want to save neglectable memory and a lot of FPU performance.

Both single-precision and double precision floating point formats do lose precision once the number gets big enough, actually.

The main issue with current approach involves the design of IEnergyContainer interface. Since it's a central piece of API for GTEU, we can't change the contract without commiting to major scale compat break.

Not to mention floating points have numerous quirks such as NaN, infinity, equal-but-not-equal values and such, so I'd say floats are unviable as a replacement for current API.