view rvinterf/include/limits.h @ 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 ca6e969be6ee
line wrap: on
line source

/*
 * For sizing our buffers etc in the rvinterf suite, including the local
 * UNIX domain socket protocol between rvinterf and fc-tmsh etc, we need
 * to have some limits on the message sizes in both host->target and
 * target->host directions.
 *
 * For the host->target direction, the choice of message size limit is
 * easy: the packet Rx code in RVT on the target side also has a limit
 * (quite naturally, as it needs to use a static buffer to reassemble
 * incoming packets as they arrive at the UART in unpredictable interrupt-
 * sized chunks), so we set our limit to match that in RVT.
 */

#define	MAX_PKT_TO_TARGET	255

/*
 * In the other direction (target->host), there is no fixed limit
 * definition easily visible in the target fw code: any fw component
 * can call rvt_send_trace_cpy() or rvt_mem_alloc() followed by
 * rvt_send_trace_no_cpy(), or some higher-level API that reduces to
 * these functions, with a message of any size, subject only to memory
 * limits, which obviously aren't as strict as a #define'd maximum
 * message size.  Hence in this direction we use our own arbitrary
 * choice of size limit.
 */

#define	MAX_PKT_FROM_TARGET	512

/*
 * Both limit definitions above counts all bytes between the opening and
 * closing STX flags, but not DLEs inserted for binary transparency.
 */