Re: c++: invalid conversion from 'int' to 'const char*'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Boris Samorodov wrote:
> On Sat, 12 Sep 2009 12:41:43 +0200 Fabian Keil wrote:
>> Boris Samorodov wrote:
>
>>> I'm porting a c++ application to FreeBSD. I've got an error:
>>> -
>>> ~/work/src/FileChannel.cpp: In member function 'QString
>>> FileChannel::errorString()':
>>> ~/work/src/FileChannel.cpp:251: error: invalid conversion from 'int' to
>>> 'const char*'
>>> ~/work/src/FileChannel.cpp:251: error: initializing argument 2 of 'char*
>>> strcpy(char*, const char*)'
>>> *** Error code 1
>>> -
>>>
>>> A simle patch makes the application to be compiled without errors:
>>> -
>>> --- src/FileChannel.cpp.orig2009-09-12 13:08:28.0 +0400
>>> +++ src/FileChannel.cpp 2009-09-12 13:08:41.0 +0400
>>> @@ -248,7 +248,7 @@
>>>
>>> QString FileChannel::errorString()
>>> {
>>> -strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
>>> +strcpy(lastErrorString, "XXX: Fix me: errno should be here");
>>> return QString(trUtf8(lastErrorString));
>>> }
>
>> At least to me, this looks like a bug in the program you are porting.
>> I don't see how this would work on other platforms either, unless
>> the libc strerror_r() is shadowed which seems unlikely.
>
> It compiles at linux (with warning though). ;-)
>
>> I assume someone replaced strerror() with strerror_r() and
>> missed the differences. The third argument of strerror_r()
>> being zero looks strange, too.
>
>>> If I understand correctly, an integer value which is returned by
>>> strerror_r() should be converted to const char*.
>>>
>>> I have _very_ basic knowledge about c++. Hence my question.
>>> Can someone provide a patch (a proof of concept)? Thanks!
>
>> You could try replacing the strerror_r() call with strerror(errno).
>> It wouldn't be thread-safe, but should at least work most of the
>> time.
>
> Aha, the following patch helps:
> -
> --- src/FileChannel.cpp.orig 2009-09-12 15:09:00.0 +0400
> +++ src/FileChannel.cpp 2009-09-12 15:11:23.0 +0400
> @@ -248,7 +248,7 @@
>
> QString FileChannel::errorString()
> {
> -strcpy(lastErrorString, strerror_r(errno, lastErrorString, 0));
> +strcpy(lastErrorString, strerror(errno));
> return QString(trUtf8(lastErrorString));
> }
>
> -
>
>> If the application is threaded, a better fix would be not to use
>> strcpy() at all. strerror_r() already puts the error description
>> into the buffer, so there's no need to copy anything. To do this,
>> you'd still need to fix the third argument, though.
>
>> If lastErrorString is an array you could use sizeof(lastErrorString),
>> if it's a pointer you could look for a malloc() call that allocates
>> the buffer to figure out the size.
>
> Thanks for your suggestions, much appreciated.
>
>> Either way, you should probably report the problem upstream.
>
> Yep, it has been already done. The author said he'll fix it at
> the next release but he have no time ATM. While I try to create
> a port with the current release.
>
According to the man pages supplied with GNU gcc, this is a GNU extension.
(The following is from a
Linux system, but I suspect it's similar to the gcc port on FreeBSD.)
> NAME
>strerror, strerror_r - return string describing error number
>
> SYNOPSIS
>#include
>
>char *strerror(int errnum);
>
>int strerror_r(int errnum, char *buf, size_t buflen);
>/* XSI-compliant */
>
>char *strerror_r(int errnum, char *buf, size_t buflen);
>/* GNU-specific */
>The XSI-compliant strerror_r() is preferred for portable applications.
>It returns the error string in the user-supplied buffer buf of length
>buflen.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqsIq4ACgkQjkAlo11skePOdACfSFAVWlkGskL9lOhzNYdmNAgq
9TYAoJqCRlVdA2rSzv3qXYD0ck6d/hJg
=qsX9
-END PGP SIGNATURE-
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: The question of moving vi to /bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 per...@pluto.rain.com wrote: >> ed is an interactive program, and it has always been considered as >> such, at least since BSD 4.2. Way back then there were three main >> editors, ex, vi, and ed. > > ed goes back at least as far as the Bell Labs 6th Edition (PDP-11), > where it was the only editor in the distribution. ex and vi (and > termcap, without which there would be no vi) were written later, at > UC Berkeley. > >> If you had a nice video terminal then you used vi. But if you >> were stuck using a hard copy terminal like a Decwriter, then you >> used ex. And ed was the simplified (dumbed down) editor for >> newbies. > > More like, ed was the "original" Unix editor; ex and vi presumably > were inspired, at least in part, by a desire to improve on ed's > limitations. I doubt I'm the only one who muttered about the bother > of horsing around with ed, back when there was nothing else. > Ah, I didn't know that. When I started using Unix (on a BSD 4.2 system) vi was the editor of choice. It wasn't until much later that I learned about the ATT side of Unix. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpEH+IACgkQjkAlo11skeOOrwCbBrOYlc7+bHDOgKvHiLedCQof w3AAniMByMDTGAIEbWzTd+oTNVgB6VoU =0dSg -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: The question of moving vi to /bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ruben de Groot wrote: > On Thu, Jun 25, 2009 at 01:36:31AM -0400, John L. Templer typed: >> ed is an interactive program, and it has always been considered as such, >> at least since BSD 4.2. Way back then there were three main editors, >> ex, vi, and ed. If you had a nice video terminal then you used vi. But >> if you were stuck using a hard copy terminal like a Decwriter, then you >> used ex. And ed was the simplified (dumbed down) editor for newbies. >> >> ed is an interactive program because the user "interacts" with it. You >> give it command, it does something, you give it some more commands, it >> does more stuff, etc. Interactive does not mean screen based. > > ed can be used very well non-interactively. > e.g. a script made by diff -e can be piped to it. > > Ruben > > Yes, that's true. Perhaps I misspoke myself. ed can be used both in interactive mode and in a script, which is what I called "command line mode". However it's not correct to say that ed is not an interactive program, as it definitely can be used interactively. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpEHekACgkQjkAlo11skePV5ACcCZaOsxztyNyWIlNBuTMuL/nu FAYAnRiKFxy+nezfkA0I9Q6Nou9Sc2Ve =SEx6 -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: The question of moving vi to /bin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manish Jain wrote: >> >> If you want to make a case for replacing ed(1), you're going to have >> to come up with some concrete reasons for doing so, not just make a >> (long and hyperbolic) statement that you don't like it. >> > > Any Unix tool has to clearly fall either under the category of > non-interactive (grep, sed, ex) or interactive (vi, wget, sysinstall). Oh really? Many Unix programs have traditionally had both a command line mode of operation and an interactive mode, and that's still pretty much still true. Usually when you run a program you put arguments on the command line, and the program does what those arguments tell it to do. But for many programs, if you run them with no arguments they run in interactive mode and wait for the user to issue commands telling the program what to do. > The case of non-interactive tools is simple : just do what you are told > on the commandline and exit. For interactive tools, at a minimum, the > application has to be show what data it is working on and what it does > with the data when the user presses a key (or a series of them). ed was > never meant to be non-interactive, and it does not fulfil the basic > requirements of being interactive. That's one reason. Secondly, how many > times does an average commandline user even think of using ed when he > needs to edit a file, even in the extreme case where there are no > alternatives ? ed is an interactive program, and it has always been considered as such, at least since BSD 4.2. Way back then there were three main editors, ex, vi, and ed. If you had a nice video terminal then you used vi. But if you were stuck using a hard copy terminal like a Decwriter, then you used ex. And ed was the simplified (dumbed down) editor for newbies. ed is an interactive program because the user "interacts" with it. You give it command, it does something, you give it some more commands, it does more stuff, etc. Interactive does not mean screen based. > > Till the improvements are in place, we need the alternative of having vi > under /bin rather than /usr/bin. > > Actually, it surprises me to what extent the core of the FreeBSD > community is enamoured with this idea of a micro-minimalistic base, in > which it is practically impossible to do anything except run fsck. > Matters don't stop there. Seeing the limitations of this approach, the > community churns up wierd workarounds like /rescue/vi, when all that was > needed was shift vi from /usr. You talk about the need for compliance > with old hardware and embedded systems to save a few kilos. How old is > the hardware that you have in mind ? The oldest system running FreeBSD I > know of is a 1997 Pentium with a 2 GB disk, and even that can easily > withstand the change I am suggesting. Machines older than that are > actually DEAD and don't have to be factored in. As for embedded systems, > the primary target of FreeBSD is servers, workstations and *tops. The > embedded world hasn't survived riding on FreeBSD, nor the other way > round. So from the viewpoint of the greatest good of the largest number, > over-indulging a mindset fixed around minimizing the base only leads to > degradation, not improvement. Getting to boast of a 900K / won't do any > good when people are thinking of having decent firepower (even while in > single-user mode) and its ease of use. It's not just keeping the core system small, it's ensuring that if the disk containing /usr fails to mount, then you still have enough of the system to fix the problem. Admittedly this isn't as much of a concern now, what with rescue disks and CDs with bootable live systems, but it's still nice to have. John L. Templer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpDDM0ACgkQjkAlo11skePG4wCgjq4plp71Yattn34UP9YIyv4k VagAoKDcLGVPQBxae6FABGa5hLI9w4gM =+Ed7 -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Extract Songs from DVD
Polytropon wrote: > On Thu, 23 Oct 2008 02:35:25 -0400, "John L. Templer" <[EMAIL PROTECTED]> > wrote: >> Polytropon wrote: >>> % dd if=/dev/acd0t01 of=track01.cdr bs=2352 >> Very cool! I have a few questions though. I notice this doesn't work >> for my Plextor CD writer. > > What, dd doesn't work from Plextor writer? I had (or, still have) > a Plextor CD writer which is SCSI, so I just have to change the > command in order to read from the correct device, which is /dev/cd0 > for the first SCSI CD drive: > > % dd if=/dev/cd0t01 of=track01.cdr bs=2352 > > Of course, you would have to change other commands in order to get > this correct, for example: > > % cdcontrol -f /dev/cd0 info > > > >> I assume this is because CD and DVD drives >> have different drivers? > > Maybe, but I think these basic things rely on the same commands > internally. > > > >> Also, does this use libparanoia or something >> similar to extract "recalcitrant" tracks? > > No, dd reads block-wise. There's dd_rescue which is able to read > from defectively manufactured media (we call them "Un-CDs" or > "Un-DVDs" in Germany). > > Another option, by the way, is to use cdrdao. It has the read > command in combination with a paranoia level switch which can be > adjusted in order to read mentioned media. As far as I remember, > you need to have the atapicam facility in your kernel (custom > compile kernel or module) in order to access ATAPI devices just > like SCSI devices. > > % camcontrol devlist > > will then show you which device equals /dev/cd0, e. g. 0,0,0 > (1st SCSI controller, 1st device, 1st LUN). > > > > If I did misunderstand the question, just post another one. :-) > (English is not my native language.) Actually, I was referring to having individual device files for each track on the CD. When I put an audio CD in the Plexwriter CD writer, it doesn't create the device files for the tracks. However when I put it in the DVD reader it does create acd0t01 through acd0t11, or however many tracks are on the CD. My Plexwriter is SCSI, but the DVD drives are IDE. Under Solaris x86 or Ubuntu Linux I have to use an application like cdrecord or soundjuicer to extract the audio tracks. These applications bypass the device files and go straight to the SCSI interface layer. libparanoia is a library that handles the tricky bits of reading the data off the CD. Just using dd to copy the data from the device file often results in corrupted data. I was wondering if the BSD kernel (or devd or whatever) uses a similar method of handling all the different variations that audio format CDs have. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Extract Songs from DVD
Polytropon wrote: > On Wed, 22 Oct 2008 17:34:41 +0300, "Odhiambo Washington" <[EMAIL PROTECTED]> > wrote: >> I bought an original DVD but I cannot play that in my car's audio >> player. Is there a tool that I can use to get the songs off the DVD in >> WAV format, or even MP3? > > If the DVD does contain standard audio CD format data, there should > be no problem. First, check the contents: > > % cdcontrol info > > (I'll assume that /dev/acd0 is the drive the DVD is inserted into.) > > Then you can access every track via /dev/acd0txx, where xx is from 01 > up to the number of tracks. Tracks can be copied from the DVD with > the dd command: > > % dd if=/dev/acd0t01 of=track01.cdr bs=2352 Very cool! I have a few questions though. I notice this doesn't work for my Plextor CD writer. I assume this is because CD and DVD drives have different drivers? Also, does this use libparanoia or something similar to extract "recalcitrant" tracks? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.1-PRELEASE sporadically panicking with fatal trap 12
I'm running 7.1-PRERELEASE, with /usr/src and /usr/ports last csup-ed
just a few days ago. After being up for about a day or so the system
will panic because of a page fault. I'm not completely sure, but it
seems that the system is more stable when gdm and gnome are disabled in
rc.conf. At least it stayed up for several days when I did that.
I've run memtest several times, so I'm pretty confident it's not a
memory problem. Also the stack trace is always the same, so I'm
thinking it's not hardware related.
I've attached a stack trace from kgdb, and the output from dmesg. I'd
appreciate any help you could give me with this.
/var/crash# kgdb -n 5
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Unread portion of the kernel message buffer:
acd1: WARNING - READ_TOC read data overrun 18>12
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x188
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0782714
stack pointer = 0x28:0xe52aec00
frame pointer = 0x28:0xe52aec18
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 18 (swi6: task queue)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 8h10m38s
Physical memory: 1779 MB
Dumping 195 MB: 180 164 148 132 116 100 84 68 52 36 20 4
Reading symbols from /boot/kernel/sound.ko...Reading symbols from
/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/snd_cmi.ko...Reading symbols from
/boot/kernel/snd_cmi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_cmi.ko
Reading symbols from /boot/kernel/acpi.ko...Reading symbols from
/boot/kernel/acpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from
/boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/mach64.ko...Reading symbols from
/boot/kernel/mach64.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/mach64.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from
/boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
#0 doadump () at pcpu.h:196
196 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:196
#1 0xc078fae7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
#2 0xc078fda9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:572
#3 0xc0aa174c in trap_fatal (frame=0xe52aebc0, eva=392)
at /usr/src/sys/i386/i386/trap.c:939
#4 0xc0aa19d0 in trap_pfault (frame=0xe52aebc0, usermode=0, eva=392)
at /usr/src/sys/i386/i386/trap.c:852
#5 0xc0aa238c in trap (frame=0xe52aebc0) at /usr/src/sys/i386/i386/trap.c:530
#6 0xc0a8827b in calltrap () at /usr/src/sys/i386/i386/exception.s:159
#7 0xc0782714 in _mtx_lock_sleep (m=0xc4ff804c, tid=3302734576, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339
#8 0xc078ed66 in _sema_post (sema=0xc4ff804c, file=0x0, line=0)
at /usr/src/sys/kern/kern_sema.c:79
#9 0xc0513350 in ata_completed (context=0xc4ff8000, dummy=1)
at /usr/src/sys/dev/ata/ata-queue.c:481
#10 0xc07c2e15 in taskqueue_run (queue=0xc4dbab80)
at /usr/src/sys/kern/subr_taskqueue.c:282
#11 0xc07c3123 in taskqueue_swi_run (dummy=0x0)
at /usr/src/sys/kern/subr_taskqueue.c:324
#12 0xc076f8db in ithread_loop (arg=0xc4dadb30)
at /usr/src/sys/kern/kern_intr.c:1088
#13 0xc076c449 in fork_exit (callout=0xc076f720 ,
arg=0xc4dadb30, frame=0xe52aed38) at /usr/src/sys/kern/kern_fork.c:804
---Type to continue, or q to quit---
#14 0xc0a882f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264
(kgdb) up 7
#7 0xc0782714 in _mtx_lock_sleep (m=0xc4ff804c, tid=3302734576, opts=0,
file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:339
339 owner = (struct thread *)(v & ~MTX_FLAGMASK);
(kgdb) list
334 * If the owner is running on another CPU, spin until
the
335 * owner stops running or the state of the lock changes.
336 */
337 v = m->mtx_lock;
338 if (v != MTX_UNOWNED) {
339 owner = (struct thread *)(v & ~MTX_FLAGMASK);
340
