IT Industry Trivia: When Two 'Justices' Collide: The True Nature of Standards Schisms Hidden in Software

In the world of software development, the phenomenon of "standards schisms"—where specifications or behaviors split into two—often occurs.
It tends to prompt the question, "Which one is correct?", but in reality, each simply has its own historical and technical background.

This time, we'll introduce some examples related to these "two standards."

Depending on the programming language, the starting point for array indices is broadly divided into three patterns.

Most modern mainstream languages start array indices at "0". This is because it aligns well with the hardware.

Representative language examples:

• C / C++
• Java / Kotlin
• Python / JavaScript
• C# / Go / Rust
• Swift / Ruby / Perl

In these languages, the first element of array a is accessed with a[0].
This is based on the low-level design concept of referencing by adding an offset (0, 1, 2, ...) to the array's base address.

For example, let's say the array a is stored in consecutive memory as follows:

The important point here is:

The actual access to a[n] is based on "base address + n-th offset."

In other words, a[0] means "the 0th element from the start (=the start itself)", which is very natural for pointer-arithmetic-based languages like C.

Also, at the machine-code level, using 0 as the "reference" is easier to handle, making 0-based indexing more efficient.

Languages that prioritize mathematical consistency adopt 1-based indexing to match the natural numbers.

Representative language examples:

• FORTRAN / R / COBOL
• Lua / MATLAB / Julia
• Smalltalk

In mathematics, array (or sequence) indices usually start at "1":

• Matrices: $A_{1,1}, A_{1,2}, ..., A_{n,m}$
• Summation notation: $\sum_{i=1}^n a_i$
• Fibonacci sequence: $F_1 = 1, F_2 = 1, F_3 = 2,...$

This is based on the intuitive notion of "counting", where the "first item is the 1st."
In languages like FORTRAN and R, which focus on scientific computing and formula processing, 1-based indexing feels more natural.

For example, in R, x[1] refers to the first element.
This matches the mathematical intuition (the first is number 1) and is natural for representing matrices and sequences.

There are also languages that allow flexible specification of index ranges.
This design lets you choose either 0-based or 1-based indexing.

Representative language examples:

• Pascal (range specification like array[1..10] is possible)
• Ada (explicit definition such as array(0..9) or array(1..10))
• Fortran (you can specify the starting point like dimension(0:9))
• VB.NET (you can change between 0-based or 1-based using Option Base)

This flexibility is helpful for index design that suits specific needs.

• "0"-based: emphasizes memory efficiency and low-level operation optimization
• "1"-based: emphasizes mathematical naturalness and formula readability
• Customizable: enables flexible, high-abstraction-level design

The key is not which is "correct", but that the appropriate choice is made based on the purpose and context.

• "0"-based is a design philosophy emphasizing implementation efficiency based on hardware structure and pointer offsets
• "1"-based is a philosophy emphasizing mathematical naturalness and readability, a legacy of formula-oriented culture

It's not about which is "correct", but that the "appropriate" choice varies by purpose and background.
0-based vs 1-based reflects differences in where you place the axis of your worldview.

Byte order (endianness) refers to the difference in which byte to store first when placing multibyte data (e.g., 16-bit, 32-bit, 64-bit integers) into memory.

• Definition: Store the Most Significant Byte (MSB) first (at the lower memory address)
• Examples of use: Network communications (TCP/IP standard), some RISC architectures (SPARC, older PowerPC, etc.)

Example: Storing 0x12345678 (in order of increasing addresses)

Big Endian: [0x12][0x34][0x56][0x78]

• Philosophy: Designed to be intuitive to read by placing higher-order bytes first, similar to decimal notation
• Background: Some instruction set architectures were designed so that "opcode → operand" appear in that order

• Definition: Store the Least Significant Byte (LSB) first (at the lower memory address)
• Examples of use: Intel CPUs (x86, x86_64), ARM (default is Little Endian)

Example: Storing 0x12345678

Little Endian: [0x78][0x56][0x34][0x12]

• Philosophy: Optimized for processors that often process from the lower-order byte first in numeric operations
• Background: Some designs favored reading only the lower-order byte first for operations like jumps

This difference is not just a matter of taste but stems from different priorities in early hardware architecture designs.

• Big Endian: Prioritizes readability for humans and visibility of instructions (e.g., opcode first, then high-order operands)
• Little Endian: Optimized for the processor's convenience in handling arithmetic operations from the lower-order side

In cross-network communication or binary file interoperability, mismatched endianness can cause bugs or data corruption.

For example:

• TCP/IP uses Big Endian (network byte order) by standard
• Windows binary files use Little Endian (Intel)
• Sending a struct between different endianness environments can scramble field interpretations

In environments where Big Endian and Little Endian coexist, explicit conversion or adjustment measures are required. Common approaches include:

• Using APIs like htonl() / ntohl() to convert between host and network byte order (common in C and system programming)
• Specifying endianness in file formats
  Example: WAV, PNG, TIFF, etc., include byte order in their specifications
• Agreeing on order at the protocol level
  Example: Protocol Buffers and MessagePack are designed to be used without worrying about byte order

Recognizing differences in endianness and handling them explicitly is crucial for building reliable software.

When calling a function, arguments are usually pushed onto the stack and passed that way.

There are two key points to watch:

1. In what order are arguments pushed onto the stack—front (left) to back (right) or back to front?
2. After the call, who cleans up the argument area on the stack?
   • The caller
   • The callee

These differences are called "calling conventions" and vary by architecture and platform.
If not understood correctly, the stack can become corrupted after a function call, leading to unexpected behavior or crashes.

• Right-to-Left (push from back):
  The most common method (e.g., cdecl)

  • Works well with variadic arguments (like printf())
  • Pushes the last argument first

• Left-to-Right (push from front):
  Pascal-family calling conventions (e.g., pascal, fastcall)

  • Poor fit for variadic arguments (like printf())
  • Pushes the first argument first

• caller clean-up (caller cleans the stack):
  Representative: cdecl

  • Easier to support variadic arguments
  • The caller must know the number of arguments

• callee clean-up (callee cleans the stack):
  Representative: stdcall

  • Keeps the caller side simple
  • The number of arguments must be fixed

Consider calling sum(a, b, c).

■ Right-to-Left (push from back): cdecl, etc.

int result = sum(1, 2, 3);  // caller

In this case, the stack is pushed in this order:

push 3  ← last argument
push 2
push 1  ← first argument
call sum

→ On the stack, the last argument ends up on top.
→ Good compatibility with variadic arguments (e.g., printf("%d", x)).
→ The caller cleans up the stack.

■ Left-to-Right (push from front): pascal, fastcall, etc.

result := sum(1, 2, 3);  // Pascal-style call

In this case, the stack is pushed in this order:

push 1  ← first argument
push 2
push 3  ← last argument
call sum

→ On the stack, the argument order is preserved as-is.
→ Readable and has high visibility but is unsuitable for variadic arguments.
→ Often the callee cleans up the stack.

• Register-based passing (fastcall, vectorcall, etc.) was introduced to speed up function calls.
• Different ABIs can lead to incompatibility between libraries and binaries.
• Notably, Windows and Linux have different default calling conventions (e.g., Windows uses stdcall-family, Linux uses cdecl-family).

• Argument pushing order and stack cleanup responsibility are defined by calling conventions.
• The appropriate choice depends on factors like variadic arguments, performance, and binary compatibility.
• In cross-platform development and interface design, it is essential to explicitly align calling conventions.

Differences in character encoding affect text processing, internationalization, file storage, communication protocols, and more. UTF-8 and UTF-16 are representative Unicode encodings, but they have distinct use cases and features.

• Features: A variable-length (1 to 4 bytes) Unicode encoding
• Compatibility: Binary-compatible with ASCII (0x00–0x7F); highly compatible with existing C strings
• Adoption Examples:
  • Web (HTML, HTTP, JSON, etc.) standards
  • File systems in Linux / macOS
  • Languages like Go, Rust, Python
• Advantages:
  • Compact for content dominated by English text
  • Strong for communication and storage
• Disadvantages:
  • Hard to perform random access (one character ≠ one byte)

• Features: A Unicode encoding using mainly 2 bytes (or 4 bytes)
• Compatibility: Not ASCII-compatible (even ASCII characters use 2 bytes)
• Adoption Examples:
  • Internal Windows APIs (since Windows NT)
  • Java’s char type, .NET’s System.String
• Advantages:
  • Efficient for East Asian text (often fits in 2 bytes)
  • Easier random access (basically 2-byte units)
• Disadvantages:
  • Some characters (e.g., emojis, supplementary Kanji) require surrogate pairs (4 bytes)
  • Prone to portability and binary incompatibility issues

In UTF-16, characters above U+10000 (e.g., some emojis and historic characters) are represented with two 16-bit values (surrogate pairs).
Programs that cannot handle this correctly may suffer from mojibake, crashes, or security vulnerabilities.

The Japanese-specific encoding Shift_JIS is still used in some contexts (legacy Windows software, emails, CSV, etc.).

• Byte-level ambiguities (e.g., 0x5C may be "¥" or "")
• Problems often arise in conversion between Unicode and Shift_JIS
• In environments mixing UTF-8, UTF-16, and Shift_JIS, mojibake, improper processing, and parsing difficulties frequently occur

Choosing an encoding requires understanding the target system, data, and compatibility requirements. In cross-language or cross-environment development, explicit conversion and checks are crucial.

Text file newline codes (line-ending characters) vary by OS and tools due to historical reasons, often causing compatibility or version control issues.

• diff shows changes for every line
  Files appear fully changed due to different newline codes
• Mojibake / build failures
  Scripts created on Windows fail on Linux with ^M errors
• Git management confusion
  Newline changes are repeatedly detected as modifications

• In Git, explicitly control newline codes with .gitattributes:

  * text=auto
  *.sh text eol=lf
  *.bat text eol=crlf
  

• Standardize settings in editors (e.g., VSCode, IntelliJ)
• Add newline checks in CI (continuous integration)

• Mismatched newline codes can be a major friction point in team development and cross-platform environments.
• Setting rules early and automating/enforcing them is key to avoiding pitfalls.

Floating-point rounding methods are critical to calculation precision and business accuracy. There are different conventions in scientific/technical contexts and commercial contexts regarding how to round halfway values (e.g., 2.5).

• Definition: Halfway values (e.g., 2.5, 3.5) are rounded to the nearest even number
• Also known as: "Bankers' rounding"
• Characteristics:
  • Aims to eliminate bias in rounding direction
  • Has a statistical effect of canceling out rounding errors in aggregation
• Examples:
  • 2.5 → 2 (even)
  • 3.5 → 4 (even)
  • 1.25 → 1.2 (when rounded to one decimal place)

• Definition: .5 values are always rounded in the direction away from zero
• Characteristics:
  • Closer to user intuition
  • Widely used in accounting and financial calculations
• Examples:
  • 2.5 → 3
  • -2.5 → -3
  • 1.25 → 1.3 (when rounded to one decimal place)

• Rounding rules can be legally defined for tax or interest calculations.
• In microsecond-level timing or simulations, accumulated rounding errors can produce critical results.
• If rounding methods are not specified in specifications, implementers may exhibit different behavior.

• IEEE 754: Strives for statistical neutrality
• Commercial Rounding: Natural for users and suitable for financial calculations

Choose rounding rules deliberately and make it a habit to specify them explicitly.

In numeric notation, the symbol used for the decimal point varies by country or culture. This difference can cause serious confusion in CSV parsing, Excel data interpretation, and software internationalization.

→ Period and comma usage are completely opposite!

• CSV files treat "3,14" as a string
  In English-configured Excel or Python, commas are seen as separators, causing errors
• Numeric calculations fail
  Automatic parsing fails, and addition/aggregation does not work correctly
• Behavior differences by Excel locale
  • In Japanese/English settings, period is decimal and comma is thousands separator
  • In German settings, comma is decimal and period is thousands separator

• Specify locale when reading CSV (Excel or pandas)
  Example: pd.read_csv("file.csv", sep=";", decimal=",")
• Design UI with user locale in mind
• Use a common internal notation (e.g., period) and convert at I/O boundaries

import pandas as pd

# Handling German-locale CSV
df = pd.read_csv("data.csv", sep=';', decimal=',')

• Decimal point notation varies drastically by country.
• Be especially careful with CSV and Excel. Locale misunderstandings are common.
• A practical approach is unified internal notation + locale-aware I/O conversions.

When representing file paths (directory structures), the separator character differs by OS.
These differences impact cross-platform development, shell scripts, and library interoperability.

• In Windows, backslash also serves as an escape character, so be careful

  • e.g., \n means newline, \t means tab
  • You may need to escape paths like "C:\\path\\to\\file"

• In some languages like Python, slashes are also accepted for Windows paths

  # Works on Windows too
  path = "C:/Users/YourName/Documents"
  

• Use language/environment-independent methods:

  • Python: os.path.join() or pathlib.Path
  • Java: Paths.get() or File.separator
  • .NET: Path.Combine()

• Use slashes in scripts and config files to maintain Unix compatibility

• Clearly distinguish between absolute and relative paths
  Path resolution issues can often arise in shell scripts or CI/CD.

Many IDEs (Visual Studio Code, IntelliJ, etc.) internally handle OS-dependent path separators.
However, be cautious with external files (CSV, batch scripts, Makefile, etc.).

• Differences in path separators can be a minefield causing unexpected failures.
• The key is to use OS-independent APIs internally and explicit rules for external notation.

As we've seen, the software development field often encounters cases of "two standards."
These are not just confusion or schisms but rather the result of optimizations based on distinct technical backgrounds, histories, and purposes.

Such differences are sometimes jokingly called "religious wars," but in reality, they mostly represent choices based on design philosophy, compatibility, and maintainability.

The question isn't "Which one is correct?" but rather
"Why is it that way?" and "How can we reconcile them?".

To operate smoothly in practice, you need two things:

• To know that there are two (or more) options
• To be flexible and adapt as needed

Rather than being swayed by specification and standard differences,
the technical and coordination skills to adapt to others demonstrate professionalism.