G. Branden Robinson writes:
> If someone got a contract with O'Reilly or No Starch Press to write a
> book on BPF and how revolutionarily awesome it is, it's conceivable they
> would be faced with exposing some BPF-related function declarations in
> the text. In cases like the following, what would you have them do?
>
> int bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
I imagine that the author or editor would break it over two lines like
int bpf_map_update_elem(struct bpf_map *map, const void *key,
const void *value, u64 flags)
or maybe the slightly uglier
int bpf_map_update_elem(struct bpf_map *map, const void *key,
const void *value, u64 flags)
I just looked in _Advanced Programming in the Unix Environment, Third
Edition_ by Stevens and Rago (published by Addison Wesley rather than
either of the fine publishers you mentioned), and it didn't take long
to find a C function prototype that was split across two lines in the
former style, on p. 880
sem_t *sem_open(const char *name, int oflag, ... /* mode_t mode,
unsigned int value */ );
... or on the next page, a better example because of the absence of the
comment:
ssize_t sendto(int sockfd, const void *buf, size_t nbytes, int flags,
const struct sockaddr *destaddr, socklen_t destlen);
It's convenient that C's rules for whitespace semantics make all of
these line-wrapped prototypes have exactly the same meaning as their
un-line-wrapped equivalents, so programmers reading the books shouldn't
have cause to be confused by this. It could be more challenging in a
language like Python, although there, too, there are syntactically
valid ways to break up some kinds of long lines.
