On 02/03/2016 08:54 AM, Programmingkid wrote:
>> Oops, I shouldn't be writing emails late at night. Let's try this again.
>
> So you want this:
>
> #if defined(__APPLE__) && defined(__MACH__)
> if (*bsd_path) {
> filename = bsd_path;
> }
> /* if a physical de
On Feb 2, 2016, at 11:36 PM, Eric Blake wrote:
> On 02/02/2016 09:21 PM, Programmingkid wrote:
>
#if defined(__APPLE__) && defined(__MACH__)
/* if a physical device experienced an error while being opened */
if (strncmp((*bsd_path ? bsd_path : filename), "/dev/", 5) ==
Am 02.02.2016 um 20:29 hat Eric Blake geschrieben:
> On 02/02/2016 10:28 AM, Programmingkid wrote:
>
> >> Whats the rationale here ? Using pre-allocated fixed
> >> length arrays is pretty bad practice in general, but
> >> especially so for filenames
> >
> > With an automatic variable there is no
On 02/02/2016 09:21 PM, Programmingkid wrote:
>>> #if defined(__APPLE__) && defined(__MACH__)
>>>/* if a physical device experienced an error while being opened */
>>>if (strncmp((*bsd_path ? bsd_path : filename), "/dev/", 5) == 0) {
>>>print_unmounting_directions(*bsd_
On Feb 2, 2016, at 9:30 PM, Eric Blake wrote:
> On 02/02/2016 06:15 PM, Programmingkid wrote:
>
>>> No, keep filename as a const char * pointer. It's easy to avoid use of
>>> uninitialized memory. Try this:
>>>
>>> const char *filename;
>>> char bsd_path[MAXPATHLEN] = "";
>>> ...
>>> if (strn
On 02/02/2016 06:15 PM, Programmingkid wrote:
>> No, keep filename as a const char * pointer. It's easy to avoid use of
>> uninitialized memory. Try this:
>>
>> const char *filename;
>> char bsd_path[MAXPATHLEN] = "";
>> ...
>> if (strncmp("/dev/cdrom"...) {
>>bsd_path = ...
>> }
>> ...
>> i
On Feb 2, 2016, at 5:04 PM, Eric Blake wrote:
> On 02/02/2016 02:23 PM, Programmingkid wrote:
>
>>> And why isn't bsd_path usable for that purpose?
>>
>> After trying it out, I found out why bsd_path isn't usable for that purpose.
>> It is because the user might try to use a flash drive as the
On 02/02/2016 02:23 PM, Programmingkid wrote:
>> And why isn't bsd_path usable for that purpose?
>
> After trying it out, I found out why bsd_path isn't usable for that purpose.
> It is because the user might try to use a flash drive as the the cdrom. Say a
> flash drive is set to /dev/disk2s9.
On Feb 2, 2016, at 2:24 PM, Eric Blake wrote:
> On 02/02/2016 12:10 PM, Programmingkid wrote:
>
>>> There was/is no leak because it qdict_get_str() returns 'const char *' and
>>> so nothing needs freeing. So your change is still a backwards steps IMHO.
>>
>> char filename[MAXPATHLEN];
>> snprin
On Feb 2, 2016, at 2:24 PM, Eric Blake wrote:
> On 02/02/2016 12:10 PM, Programmingkid wrote:
>
>>> There was/is no leak because it qdict_get_str() returns 'const char *' and
>>> so nothing needs freeing. So your change is still a backwards steps IMHO.
>>
>> char filename[MAXPATHLEN];
>> snprin
On 02/02/2016 10:28 AM, Programmingkid wrote:
>> Whats the rationale here ? Using pre-allocated fixed
>> length arrays is pretty bad practice in general, but
>> especially so for filenames
>
> With an automatic variable there is no worry about when to release it.
Yeah, but it comes with the dow
On 02/02/2016 12:10 PM, Programmingkid wrote:
>> There was/is no leak because it qdict_get_str() returns 'const char *' and
>> so nothing needs freeing. So your change is still a backwards steps IMHO.
>
> char filename[MAXPATHLEN];
> snprintf(filename, MAXPATHLEN, "%s", qdict_get_str(options, "fi
On Feb 2, 2016, at 12:31 PM, Daniel P. Berrange wrote:
> On Tue, Feb 02, 2016 at 12:28:24PM -0500, Programmingkid wrote:
>>
>> On Feb 2, 2016, at 12:16 PM, Daniel P. Berrange wrote:
>>
>>> On Tue, Feb 02, 2016 at 12:08:31PM -0500, Programmingkid wrote:
https://patchwork.ozlabs.org/patch/57
On Tue, Feb 02, 2016 at 12:28:24PM -0500, Programmingkid wrote:
>
> On Feb 2, 2016, at 12:16 PM, Daniel P. Berrange wrote:
>
> > On Tue, Feb 02, 2016 at 12:08:31PM -0500, Programmingkid wrote:
> >> https://patchwork.ozlabs.org/patch/570128/
> >>
> >> Mac OS X can be picky when it comes to allowi
On Feb 2, 2016, at 12:16 PM, Daniel P. Berrange wrote:
> On Tue, Feb 02, 2016 at 12:08:31PM -0500, Programmingkid wrote:
>> https://patchwork.ozlabs.org/patch/570128/
>>
>> Mac OS X can be picky when it comes to allowing the user
>> to use physical devices in QEMU. Most mounted volumes
>> appear
On Tue, Feb 02, 2016 at 12:08:31PM -0500, Programmingkid wrote:
> https://patchwork.ozlabs.org/patch/570128/
>
> Mac OS X can be picky when it comes to allowing the user
> to use physical devices in QEMU. Most mounted volumes
> appear to be off limits to QEMU. If an issue is detected,
> a message
16 matches
Mail list logo
