This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
HPUX long long issue - question
- From: "John D. Hendrickson" <johnandsara2 at cox dot net>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 13 Dec 2014 15:37:36 -0500
- Subject: HPUX long long issue - question
- Authentication-results: sourceware.org; auth=none
- Authentication-results: cox.net; none
- References: <bug-17702-131 at http dot sourceware dot org/bugzilla/>
i read a post, an HPUX user purportedly trying to compile binutils
using HPUX compiler (why sounds bogus, since these tools accompany gcc
compiler, but maybe for gas(1) let's assume but not clap for)
his compiler fails on "long long"
i recently wrote (%99 of) a working parser for K&R's CPL (it outputs
xml, the bnf for CPL a test of it)
WHY WOULD anyone inject "long long" as a syntax in C/C++ it makes no
sense. it's obviously not just a type issue. one coudl use "long2" and
that would fail. typdef. #define. they all expect a single string
(not identifier, but keyword) while parsing.
the ISSUE i see is requiring a compiler to be forced to understand
repeated type specifiers - and that this would slow down compilation
while just needing to haphasardously checking for. the issue is why one
would do it when it's completely incompatible, un-necessary, but also
unclear. but when typdef comes into the issue a whole another batch of
problems arise of how a parser must operate and be prepared to operate.
and i wonder: how is this person who did this getting keys to GNU to
just alter anything they wish on servers in the USA ? that would break
all current compilers ?
------------------------
an answer to the HPUX user's question would be to supply an input
filter, such as m4(1), so that all "long long" -> "long2", and to in top
level headers map it if need be (or let it fail if needs be). he would
use a gcc option to specify, and that would do one first then the next
as a script.
i'm accustomed to microsoft promoting the use of non-standard filters to
prefilter C code before (cc1, cpp) get the C code, but i'm sure it had
been frowned up for GNU
for GNU, failing to use indent(1) or using strange indent(1) options is
frowned upon, i had thought
"There may be pitfalls when you use long long types for function
arguments without function prototypes. If a function expects type int
for its argument, and you pass a value of type long long int, confusion
results because the caller and the subroutine disagree about the number
of bytes for the argument."
well then ISO C99 is bogus. C is supposed to convert if the program
indicated conversion - and a major feature of gcc (i've read an earlier
version) is to know the type size and emit this need to as(1). adding a
feature that can add but not divide right and doesn't convert: sounds
very hackish, like if you need instructions to use it - it shouldn't be
in there.
--------------------
i have another concern (other than deletion of ASM code from gcc (all
accel for old processors, well i guess), addition of google? Cloog and
google ld and microsoft stack fix hacks for taking gnu into their
product line) and lack of clear direction on headers to use and when
BIT HACKS being inserted into gcc causing "package dependancy issues" in
the host's whole unix distribution
bit hacks can be in separate distribution they do NOT have a need to be
integrated inside gcc
FOR EXAMPLE. i'm making X11R7. i find this in france's radeon code
they've been helping texas AMD with the linux release of i understand.
return 1 << __builtin_ctz(~n)
WHICH ONLY COUNTS BITS TO FIRST 0 BIT, IMHO
for this alone i was told i need "a new compiler". for a bit hack.
gcc binary distribution is not the place to tuck away your favorit bit
hacks. headers might be i invite that
what it does is cause false dependancy issues and forced upgrades, ie,
to a gcc which has deleted ASM for i386
what it does is cause X11R7 to fail to build for no good reason at all
i edite the code and kept compiling: i'm SURE it was the only hold-back
of upgrading from XFree86 4.8 (good, easy to compile) to X11R7 (nice
fonts, fast web browser, i will see, was hard to compile many issues)
so DELETE already working i386 strcpy, but add bithack ? but forget
better float support or bit string support?
and for that matter: gcc is not a dumping ground for "extra libs" one
may not want to use, nor should it pre-require parts of X windows to
compile (glibc does, maybe your libc doesn't)
i then also find _ctz bit hack not just used within gcc but gcc
inserting _ctz in libs, libs that are then unusuable if _ctz is not
found - while _ctz is small inline who'd know why it wasn't inline
this is akin to why linux torvals (in my own opinion) asked others not
to take and use function symbols out of "unclean" kernel headers and use
them in distro software. and i'd expect gcc develops to know why.
dependancy issues, forced upgrades, incompatibility, stopped builds,
GLIBC can't load errors, misfunctioning software and etc.
well look who's the biggest user of _ctz in gcc internal code:
gcc/longlong.h
back to header. why isn't _ctz in any head i can find in my newer
debian OS distro ? all the .o in gcc have the string a if it's a symbol
not an include. in debian no .h has a definition, and c++/4.4/bitset is
in my include/ but does not have the .h extension but uses .h terms
i'm thinking my worry is right ... that it's a very small patch of ASM
that was made a function instead of an (volatile) inline ... which is
the worst of the ways bit hacks internal to gcc could be made public for use
---------------------------
thank you all for any problem i find 1000 were taken care of
John