similar to: [MODULE] pwd

Ferenc Wagner <wferi at niif.hu> writes: > "H. Peter Anvin" <hpa at zytor.com> writes: > >> On 08/29/2013 04:14 AM, Ferenc Wagner wrote: >> >>> "H. Peter Anvin" <hpa at zytor.com> writes: >>> >>>> On 08/22/2013 10:20 AM, Ferenc Wagner wrote: >>>> >>>>> Now that Syslinux has ls.c32 and

Hi, We are using pxelinux at my company to test our product. And there are limitations that we have hit in the past w.r.t. the max length of a path, or the max length of a module name (in mboot.c / mboot.c32). We've used workarounds in the past, and reorganized the directory structure, but we face that problem again. Out of the 128 / FILENAME_MAX chars that can be used, 110 - 120 go to the

Without further adieu, I would like to announce that I've finally pushed ROSH, the Read-Only SHell, finally to the point of being reasonably usable. From: Gene Cumm <gene.cumm at gmail.com> Patch ROSH for Syslinux-4 and make it much more usable. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- diff --git a/com32/rosh/rosh.c b/com32/rosh/rosh.c index 511fdff..bf1176f

The getpwd() function in dash assumed than getcwd(0, 0) will allocate the buffer dynamically using malloc(); however, this glibc extension is not implemented by klibc. Make getpwd() use a temporary buffer and invoke savestr() itself instead of relying on a nonstandard extension. Signed-off-by: Sergey Vlasov <vsu at altlinux.ru> --- Alternatively, you may pull from the following git repo

Well, here's the read-only shell (rosh) that I've been working on. It's functional but still quite rough. My primary intention of posting it at this time is such that people have an easy way to demonstrate to themselves that the library calls I made work. This should apply as a patch to the head of the "dir" branch and the patch for c_cflag/c_lflag. The patch is only

From: Gene Cumm <gene.cumm at gmail.com> COM32: Add directory functions getcwd(), opendir(), readdir() and closedir(). This depends on the patch that I just submitted creating the COMBOOT API calls. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- The intention is to create the library calls with (hopefully) POSIX compliance such that a small application written to use these

From: Gene Cumm <gene.cumm at gmail.com> COM32: Add directory functions getcwd(), opendir(), readdir() and closedir(). This depends on the patch that I just submitted creating the COMBOOT API calls. Signed-off-by: Gene Cumm <gene.cumm at gmail.com> --- The intention is to create the library calls with (hopefully) POSIX compliance such that a small application written to use these

From: Matt Fleming <matt.fleming at intel.com> The location of __file_info[] and ansicon_counter are split between the core and ldlinux.c32. We can end up calling __ansicon_close (from fp->oop->close) in the process of reloading ldlinux.c32, and while ansicon_counter is set to its initialised data value of 0 when reloading ldlinux.c32, the core is never reloaded, and so __file_info[]

Hi, I just pushed out changes that fix pretty much all the compiler build warnings on the elflink branch. Also, I've added "auto extension" support so that if the user doesn't type the file name extension it will automatically be looked up, e.g. now typing "ls" will execute "ls.c32". The following changes since commit

Hello, The attached l32or64.c implements a com32 module that boots two different kernels with different initrds depending on whether the cpu has long mode support or not. I stumbled upon two problems while developing it with current git version (last commit 595705ffad4f63cfeb84e9bb1243df03808c2fff). The first was that syslinux_boot_linux didn't work for me. Both the command line and initrd

On Tue, Nov 09, 1999 at 11:39:39AM +0100, Mariusz Marcinkiewicz wrote: > After reading lcamtuf's posts I decided write this one. Few months ago one > of my friends - digit - found bug in linux nfsd daemon. I made example > sploit about IV 1999. Now in distributions is new nfsd and nowhere was > information about security weaknes of old version! Well, one gets used to people

Rsync 2.5.6 has a problem with pathnames or filenames longer than 255. I redefined them in rsync.h, which generated errors on make pointing to the previous definitions which look fine. Any ideas on where to check next? Here's the error I got trying to rsync: receiving file list ... done

So that it can be used in plugins. --- common/include/Makefile.am | 1 + common/include/get-current-dir-name.h | 62 +++++++++++++++++++++++++++ src/Makefile.am | 4 +- src/utils.c | 14 +----- 4 files changed, 68 insertions(+), 13 deletions(-) diff --git a/common/include/Makefile.am b/common/include/Makefile.am index bb73eec..81f4804

From: maximilian attems <max at stro.at> On review of klibc dash changes: "Hmm, this breaks the non-glibc case. You're now returning a pointer to a string on the stack which is illegal." Herbert Xu Use upstream dash way. Signed-off-by: maximilian attems <max at stro.at> Cc: Herbert Xu <herbert at gondor.apana.org.au> --- usr/dash/cd.c | 7 ++++--- 1 files

Applies to Syslinux 4.06. Attached, below, and available at: Repository: git://git.zytor.com/users/sha0/syslinux.git Branch: nictype - Shao Miller ----- From 2764e260e12d9769e3b699e4213b9a164e64924a Mon Sep 17 00:00:00 2001 From: Shao Miller <sha0.miller at gmail.com> Date: Thu, 22 Nov 2012 20:43:25 -0500 Subject: [PATCH] nictype.c32: PXELINUX module to display UNDI NIC bus

https://bugzilla.mindrot.org/show_bug.cgi?id=1748 Summary: getcwd being called with invalid argument in servconf.c Product: Portable OpenSSH Version: 5.4p1 Platform: Sparc OS/Version: Solaris Status: NEW Severity: critical Priority: P2 Component: sshd AssignedTo: unassigned-bugs

Got the following trying to build git master: gcc -std=gnu99 -m32 -fno-stack-protector -mregparm=3 -DREGPARM=3 -march=i386 -Os -W -Wall -march=i386 -fomit-frame-pointer -D__COM32__ -nostdinc -iwithprefix include -I../../com32/libutil/include -I../../com32/include -c -o chain.o chain.c ld -m elf_i386 -T ../../com32/lib/com32.ld -o chain.elf chain.o ../../com32/libutil/libutil_com.a

Commit-ID: 7154953196c34e244e0e32e73b82ec6a6c29c4e5 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=7154953196c34e244e0e32e73b82ec6a6c29c4e5 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Sun, 25 Mar 2018 16:38:00 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] expand: Fix buffer

Commit-ID: e09252abe2baa4f033807c0c77ce273a804f041a Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=e09252abe2baa4f033807c0c77ce273a804f041a Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Sun, 25 Mar 2018 16:38:00 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:54 +0000 [klibc] dash: expand: Fix

I get a link error when trying to call malloc from libcom32. I tried to simplify the case by adding the malloc to the sample hello.c in the modules directory, but I still get the following error: ld -m elf_i386 -T ../lib/com32.ld -o hello.elf hello.o ../libutil/libutil_com.a ../lib/libcom32.a /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/32/libgcc.a ../lib/libcom32.a(malloc.o)(.text+0x13): In