Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Rationale for aligning data on even bytes in a Unix shell file? Date: Sat, 26 Apr 2025 14:34:22 -0700 Organization: None to speak of Lines: 27 Message-ID: <87bjsippy9.fsf@nosuchdomain.example.com> References: MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 26 Apr 2025 23:34:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="170f7333a55fa4660e760a19e7cc9851"; logging-data="3384351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19iScusjJQZDHFxa4JcOzl9" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:Oo640gZvhPOH9zXblJ+FV+Eyz0Y= sha1:i9Dsi0mNwh1kGKxixp2BB3hqPoU= Bytes: 2083 scott@slp53.sl.home (Scott Lurndal) writes: > Janis Papanagnou writes: >>In a "C" file (of the Kornshell software) I stumbled across this >>comment: "Each command in the history file starts on an even byte >>and is null-terminated." >> >>I wonder what's the reason behind that even-byte-alignment, on "C" >>level or on Unix/files level. Any ideas? > > Possibly to support 16-bit character sets? I don't think it supports 16-bit character sets. Unlike bash history files, which are plain text, ksh history files are in a binary format. I don't know whether the format includes any multi-byte integers. If it does, reading such values directly into memory might be easier on some platforms if they're aligned. The relevant source file is src/cmd/ksh93/edit/history.c, in . It has functions to manipulate the history file, but I don't see a full description of the file format. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */