Le 01/11/2024 à 17:49, karl@??? a écrit :
> As (I think it was) Kevin wrote, don't use longjmp.
    But setjmp/longjmp exist; don't they?
>
>>     My current work is a parser for the web client request and MIME
> ...
>
> In a parser it is normal to get bogus input, it isn't exceptional.
> A parser that gives you intelligent responses is something to strive
> for.

    HTTP/1.1 is a peculiar case. It is always written by applications
and read by applications, never by humans. However it is designed to be
human-readable, which means optional white space (OWS) in *some* places,
for the only sake of human-readability, and even optional continuation
lines, so that the lines do not exceed a screen-width. In practice,
continuation lines are *never* used and OWS is *always* used where
allowed, with only one single space character, though any succession of
space, horizontal and vertical tabs, backspaces and carriage-returns is
allowed. Also the lines always end with carriage-return followed by
line-feed, though line-feed alone should be tolerated. Anyway, since the
request is written by a machine, it is not normal to get bogus input.

    When parsing human input, bogus is normal in some sense, because
humans always make errors; but the work-flow of the program changes
radically: when finding a bogus, the normal work, which consists of
interpreting the semantics and building an internal representation of
the input, just stops, and the program switches to handling the bogus,
that it issue a diagnostic, and either stop or continue to analyze
another part of the input after some clean-up. So that the situation
*is* exceptional for the program. In the case of a compiler, the bogus
case may even be more likely than the no-bogus case (~: but the work is
completely different.

--     Didier