FreeCalypso > hg > freecalypso-tools
annotate rvinterf/libg23/README @ 465:003e48f8ebe1
rvinterf/etmsync/fsnew.c: cast 0 to (char *) for execl sentinel
I generally don't use NULL and use plain 0 instead, based on a "NULL
considered harmful" discussion on the classiccmp mailing list many aeons
ago (I couldn't find it, and I reason that it must have been 2005 or
earlier), but a recent complaint by a packager sent me searching, and I
found this:
https://ewontfix.com/11/
While I don't give a @#$% about "modern" systems and code-nazi tools,
I realized that passing a plain 0 as a pointer sentinel in execl is wrong
because it will break on systems where pointers are longer than the plain
int type. Again, I don't give a @#$% about the abomination of x86_64 and
the like, but if anyone ever manages to port my code to something like a
PDP-11 (16-bit int, 32-bit long and pointers), then passing a plain 0
as a function argument where a pointer is expected most definitely won't
work: if the most natural stack slot and SP alignment unit is 16 bits,
fitting an int, with longs and pointers taking up two such slots, then
the call stack will be totally wrong with a plain 0 passed for a pointer.
Casting the 0 to (char *) ought to be the most kosher solution for the
most retro systems possible.
author | Mychaela Falconia <falcon@freecalypso.org> |
---|---|
date | Mon, 11 Feb 2019 00:00:19 +0000 |
parents | e7502631a0f9 |
children |
rev | line source |
---|---|
0
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
1 The library built in this directory is a host side library, not for the target. |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
2 This library implements some functions for handling packet exchanges with GPF, |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
3 and it will be linked by some of the programs in the rvinterf suite. |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
4 |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
5 It needs to be noted that the RVTMUX channel belonging to GPF was named |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
6 RVT_L23_HEADER by TI, and as a result, I thought that these packets related |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
7 specifically to the higher layers of the protocol stack. But now we know that |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
8 hierarchically speaking, GPF sits *below* L1, not above, and GPF packets should |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
9 not be automatically associated with G23. This realization was made fairly |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
10 late, thus "g23" appears in a bunch of function names, and in the name of this |
e7502631a0f9
initial import from freecalypso-sw rev 1033:5ab737ac3ad7
Mychaela Falconia <falcon@freecalypso.org>
parents:
diff
changeset
|
11 library. |