Missing version number in sox --version output with MacOS X clang #159

Closed
opened 2024-09-17 21:36:43 +02:00 by martinwguy · 0 comments
martinwguy commented 2024-09-17 21:36:43 +02:00 (Migrated from codeberg.org)

Missing version number in sox --version output with MacOS X clang

Description

Using SoX 14.4.2 on OS X 10.9.5, the output from sox --version is missing the version number:

$ sox --version
sox:      SoX v
$

This is using OS X 10.9.5, Xcode 6.1.1, and Apple's compiler:
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
The same result occurs using clang 3.6.

Configuring with CFLAGS=-g instead of the default -O2, it works as expected.

Looking at the assembly output, it appears that as part of its optimization the compiler replaced the call to sox_version() with a simple load of the address of the static versionstr buffer that would be returned by sox_version(). Because sox_version() does not end up being called, the versionstr buffer contains an empty string.

It appears that this occurs because the function sox_version() was declared in src/sox.h as LSX_RETURN_PURE (i.e. attribute ((pure))). However the function actually does have an important side effect, which is to fill in the versionstr buffer. The functions sox_version_info() and lsx_enum_option() also appear to have potential side effects despite being marked LSX_RETURN_PURE. Removing LSX_RETURN_PURE from these functions resolves the issue.

Repeat by

Build on MacOS X with clang then

src/sox_ng --version

Results

Tested on cfarm104 with clang 14.0.0

sox_ng:      SoX_ng v14.4.3

Analysis

This was a problem with clang-3.6, which we cannot test to confirm the problem.

We could apply it anyway, as it's probably harmless, however sox_ng.h now contains:

#ifdef __GNUC__
#define LSX_RETURN_PURE __attribute__ ((pure)) /* Function is pure. */
#else
#define LSX_RETURN_PURE /* Function is pure. */
#endif

so LSX_RETURN_PURE is removed on non-gcc compilers, achieving what the patch wants.

Conclusion

Not necessary any more.

# Missing version number in sox --version output with MacOS X clang ## Links * [`sox.sf.net` patch 104](https://sourceforge.net/p/sox/patches/104): missing version number in sox --version output ## Description Using SoX 14.4.2 on OS X 10.9.5, the output from sox --version is missing the version number: ``` $ sox --version sox: SoX v $ ``` This is using OS X 10.9.5, Xcode 6.1.1, and Apple's compiler: Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) The same result occurs using clang 3.6. Configuring with CFLAGS=-g instead of the default -O2, it works as expected. Looking at the assembly output, it appears that as part of its optimization the compiler replaced the call to sox_version() with a simple load of the address of the static versionstr buffer that would be returned by sox_version(). Because sox_version() does not end up being called, the versionstr buffer contains an empty string. It appears that this occurs because the function sox_version() was declared in src/sox.h as LSX_RETURN_PURE (i.e. __attribute__ ((pure))). However the function actually does have an important side effect, which is to fill in the versionstr buffer. The functions sox_version_info() and lsx_enum_option() also appear to have potential side effects despite being marked LSX_RETURN_PURE. Removing LSX_RETURN_PURE from these functions resolves the issue. ## Repeat by Build on MacOS X with clang then ``` src/sox_ng --version ``` ## Results Tested on cfarm104 with clang 14.0.0 ``` sox_ng: SoX_ng v14.4.3 ``` ## Analysis This was a problem with `clang-3.6`, which we cannot test to confirm the problem. We could apply it anyway, as it's probably harmless, however `sox_ng.h` now contains: ``` #ifdef __GNUC__ #define LSX_RETURN_PURE __attribute__ ((pure)) /* Function is pure. */ #else #define LSX_RETURN_PURE /* Function is pure. */ #endif ``` so `LSX_RETURN_PURE` is removed on non-gcc compilers, achieving what the patch wants. ## Conclusion Not necessary any more.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: sox_ng/sox_ng#159
No description provided.